home *** CD-ROM | disk | FTP | other *** search
/ Aminet 28 / Aminet 28 (1998)(GTI - Schatztruhe)[!][Dec 1998].iso / Aminet / dev / c / dice-3.16.lha / examples / DosHan / README < prev    next >
Text File  |  1998-09-27  |  2KB  |  59 lines
  1.  
  2.                 DOSHAN
  3.  
  4.     Example of a DOS handler under DICE.  This handler doesn't do diddly
  5.     but you can see how such a beast is supposed to work.
  6.  
  7.     No limitations in terms of models, etc.. since _main() is used along
  8.     with the standard C startup.
  9.  
  10.     Note that by compiling the handler resident it is possible to do what
  11.     the CON: handler does -- CreateProc() several copies of itself to
  12.     handle each console.  If you do NOT compile it resident, then the
  13.     device cannot fork itself off (but otherwise works fine -- multiple
  14.     filehandle references simply reference the same handler, that's all)
  15.  
  16.     This example may be compiled under 1.3 or 2.0.  To compile,
  17.     create a directory for the objects DTMP:DOSHAN/ and then run
  18.     dmake:
  19.  
  20.     1> dmake
  21.  
  22.     You may mount the test handler with (without changing directories):
  23.  
  24.     1> mount test: from mountlist.local
  25.  
  26.     And use it like this:
  27.  
  28.     1> echo "fubar" >test:x
  29.     1> echo "xxxx" >test:x
  30.     1> type test:x
  31.     fubar
  32.     xxxx
  33.     1>
  34.  
  35.  
  36.     NOTE:  DO NOT USE THIS HANDLER FOR ANYTHING REAL.  It does no
  37.     optimization of any kind and its sole purpose is as an example
  38.  
  39.                DOS HANDLER LIMITATIONS
  40.  
  41.     There is one major limitation to most dos handler implementations, this
  42.     one included.  Basically, if you use the handler's process message port
  43.     to handle incomming requests you may NOT make any DOS calls from within
  44.     the handler itself.  This is due to the design of the DOS packet
  45.     interface which precludes a message port being usable for other
  46.     purposes simultanious with a DOS packet.  Since the DOS packet's
  47.     message is never effectively ReplyMsg()d (instead it is PutMsg()d
  48.     back to the reply port), there is no easy way to tell whether it
  49.     has been replied or not without a WaitPort(), but that assumes the
  50.     first message sent to the port will be the DOS packet reply.
  51.  
  52.     Any MOUNT'd DOS handler automatically defaults to using the process
  53.     message port and there is no easy way to switch ports so the handler
  54.     may use DOS calls itself.  One solution is to run the handler manually
  55.     (make it a CLI runable program) and have it manually create the
  56.     appropriate DOS node when it starts up with a message port pointing
  57.     to a custom port instead of the process port.
  58.  
  59.